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                  Information Refresh Time Option for
         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6) option for specifying an upper bound for how long a
   client should wait before refreshing information retrieved from
   DHCPv6.  It is used with stateless DHCPv6 as there are no addresses
   or other entities with lifetimes that can tell the client when to
   contact the DHCPv6 server to refresh its configuration.
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1.  Introduction

   DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts.
   However, many hosts will use stateless autoconfiguration as specified
   in [RFC2462] for address assignment, and use DHCPv6 only for other
   configuration data; see [RFC3736].  This other configuration data
   will typically have no associated lifetime, hence there may be no
   information telling a host when to refresh its DHCPv6 configuration
   data.  Therefore, an option that can be used from server to client to
   inform the client when it should refresh the other configuration data
   is needed.

   This option is useful in many situations:

      - Unstable environments where unexpected changes are likely to
        occur.

      - For planned changes, including renumbering.  An administrator
        can gradually decrease the time as the event nears.

      - Limit the amount of time before new services or servers are
        available to the client, such as the addition of a new NTP
        server or a change of address of a DNS server.  See [RFC4076].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

3.  Information Refresh Time Option Definition

   The information refresh time option specifies an upper bound for how
   long a client should wait before refreshing information retrieved
   from DHCPv6.  It is only used in Reply messages in response to
   Information-Request messages.  In other messages there will usually
   be other options that indicate when the client should contact the
   server, e.g., addresses with lifetimes.

   Note that it is only an upper bound.  If the client has any reason to
   make a DHCPv6 request before the refresh time expires, it should
   attempt to refresh all the data.

   A client may contact the server before the refresh time expires.
   Reasons it may do this include the need for additional configuration
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   parameters (such as by an application), a new IPv6 prefix announced
   by a router, or that it has an indication that it may have moved to a
   new link.

   The refresh time option specifies a common refresh time for all the
   data.  It doesn't make sense to have different refresh time values
   for different data, since when the client has reason to refresh some
   of its data, it should also refresh the remaining data.  Because of
   this, the option must only appear in the options area of the Reply
   message.

   The expiry of the refresh time in itself does not in any way mean
   that the client should remove the data.  The client should keep its
   current data while attempting to refresh it.  However, the client is
   free to fall back to mechanisms other than DHCPv6 if it cannot
   refresh the data within a reasonable amount of time.

   When a client receives a Reply to an Information-Request that
   contains configuration information, it should install that new
   configuration information after removing any previously received
   configuration information.  It should also remove information that is
   missing from the new information set, e.g., an option might be left
   out or contain only a subset of what it did previously.

3.1.  Constants

   We define two constants for use by the protocol.  How they are used
   is specified in the sections below.

      IRT_DEFAULT 86400
         In some cases the client uses a default refresh time
         IRT_DEFAULT.  The recommended value for IRT_DEFAULT is 86400
         (24 hours).  The client implementation SHOULD allow for this
         value to be configurable.

      IRT_MINIMUM 600
         This defines a minimum value for the refresh time.

3.2.  Client Behaviour

   A client MUST request this option in the Option Request Option (ORO)
   when sending Information-Request messages to the DHCPv6 server.  A
   client MUST NOT request this option in the ORO in any other messages.

   If the Reply to an Information-Request message does not contain this
   option, the client MUST behave as if the option with value
   IRT_DEFAULT was provided.
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   A client MUST use the refresh time IRT_MINIMUM if it receives the
   option with a value less than IRT_MINIMUM.

   As per section 5.6 of [RFC3315], the value 0xffffffff is taken to
   mean "infinity" and implies that the client should not refresh its
   configuration data without some other trigger (such as detecting
   movement to a new link).

   If a client contacts the server to obtain new data or refresh some
   existing data before the refresh time expires, then it SHOULD also
   refresh all data covered by this option.

   When the client detects that the refresh time has expired, it SHOULD
   try to update its configuration data by sending an Information-
   Request as specified in section 18.1.5 of [RFC3315], except that the
   client MUST delay sending the first Information-Request by a random
   amount of time between 0 and INF_MAX_DELAY.

   A client MAY have a maximum value for the refresh time, where that
   value is used whenever the client receives this option with a value
   higher than the maximum.  This also means that the maximum value is
   used when the received value is "infinity".  A maximum value might
   make the client less vulnerable to attacks based on forged DHCP
   messages.  Without a maximum value, a client may be made to use wrong
   information for a possibly infinite period of time.  There may
   however be reasons for having a very long refresh time, so it may be
   useful for this maximum value to be configurable.

3.3.  Server Behaviour

   A server sending a Reply to an Information-Request message SHOULD
   include this option if it is requested in the ORO of the Information-
   Request.

   The option value MUST NOT be smaller than IRT_MINIMUM.  The server
   SHOULD give a warning if it is configured with a smaller value.

   The option MUST only appear in the options area of Reply messages.
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3.4.  Option Format

   The format of the information refresh time option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          option-code          |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    information-refresh-time                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code
         OPTION_INFORMATION_REFRESH_TIME (32)

      option-len
         4

      information-refresh-time
         Time duration relative to the current time, expressed in units
         of seconds

4.  IANA Considerations

   The IANA has assigned an option code for the information refresh time
   option from the DHCPv6 option-code space [RFC3315].

5.  Acknowledgements
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6.  Security Considerations

   Section 23 of [RFC3315] outlines the DHCPv6 security considerations.
   This option does not change these in any significant way.  An
   attacker could send faked Reply messages with a low information
   refresh time value, which would trigger use of IRT_MINIMUM to
   minimize this threat.  Another attack might be to send a very large
   value, to make the client use forged information for a long period of
   time.  A possible maximum limit at the client is suggested, which
   would reduce this problem.
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